fix(workspace): [workspace.build] 要作用到「作为兄弟成员依赖被编译」的成员 - #539

…pendency

Found by asking the completeness question the feature invites and not by a
failure: does `[workspace.build]` reach a member that is compiled as ANOTHER
member's `path` dependency? Measured, it did not.

    mcpp build -p appb        appb  -DWS_FLAG=1 -std=c++26
                              liba              -std=c++26      <- the sibling

Inheritance ran only where the command's own manifest is loaded, so a workspace
where members depend on each other — the ordinary shape, not an exotic one —
got the flags on one package and not on the others, in the same command.

`[workspace.package] standard` hid it. The standard is imposed graph-wide from
the root for BMI-compatibility reasons, so it reached the sibling anyway; the
gap only became reachable once a `[build]` key was inheritable too.

Two halves, applied where each one's consumer reads it:

  - `[workspace.package]` at the dependency LOAD site, because a member may
    legally omit `package.version` when the workspace supplies it, and the
    parser would otherwise refuse it for a field the workspace does provide —
    naming the member's manifest rather than the table that answers.
  - `[workspace.build]` in `makePackageRoot`, the one funnel both
    dependency-assembly sites go through, and the point at which the include
    directories are captured from the manifest. A later mutation would reach
    the flags and silently not the include dirs.

`is_workspace_member` asks the workspace's own `members` list rather than "is
this path inside the tree": a vendored copy or an example living under the
workspace is not a member, and a member's flags are exactly what it must not
acquire. 321 asserts both directions in one fixture, because a fix that
inherited to every `path` dependency would pass the positive alone.

`inherit_workspace_config` is now the composition of the two halves, so the
three call sites cannot drift.